Processing of financial transactions using debit networks

ABSTRACT

Methods and systems are disclosed for executing financial transactions between customers and merchants. An identifier of a financial account is received from the customer at a merchant system. A one-time password is also received from the customer at the merchant system, with the customer having been provided with the one-time password by a mobile electronic device or contactless presentation instrument. A cryptogram is generated to include the identifier of the financial account encrypted using the one-time password. An authorization request is formulated at the merchant system. The authorization request includes the cryptogram and transaction information describing at least a portion of the financial transaction. The authorization request is transmitted from the merchant system to an authorization processor for authorization of the financial transaction.

CROSS REFERENCE TO RELATED APPLICATION

This application is a divisional of U.S. application Ser. No.11/677,960, entitled “Processing of Financial Transactions Using DebitNetworks,” filed Feb. 22, 2007, the entire contents of which areincorporated by reference herein.

This application is related to commonly assigned, concurrently filedU.S. Pat. appl. Ser. No. 11/677,967, entitled, “MANAGEMENT OF FINANCIALTRANSACTIONS USING DEBIT NETWORKS,” filed by Vijay Royyuru and RobertFreisheim (Attorney Docket No. 20375-081000US), the entire disclosure ofwhich is incorporated herein by reference for all purposes.

BACKGROUND OF THE INVENTION

This application relates generally to financial transactions. Morespecifically, this application relates to processing of financialtransactions using debit networks.

In a modern commercial environment, there is an array of differentfinancial products that consumers have available to them in executingfinancial transactions. Some of the more prevalent forms of transactionsmay be characterized as credit transactions, debit transactions, andstored-value transactions. Each of these transactions differs in themanner in which access to funds is provided to the consumer. Forexample, credit transactions are supported by funds provided by acreditor to a customer. The principal example of such credittransactions are credit-card transactions in which the creditor issues acard to the customer that the customer may use as a presentationinstrument to identify a credit account. When the transaction isexecuted, funds are drawn against the credit account, which usually hasa pre-established credit limit, to support the transaction.

The other major types of financial transactions also make use ofpresentation instruments. A stored-value transaction is one in whichfunds have been specifically set aside and associated with apresentation instrument so that they may be used to support atransaction. In most cases, such stored-value instruments are anonymousin that the funds are associated only with the instrument and not withany particular person. This has the advantage that such instruments maybe easily transferred and they find wide utility as gift cards. Thisgift aspect is frequently reinforced by imposing restrictions on themerchant with whom transactions may be executed with the set-asidefunds.

Debit transactions may also make use of a presentation instrument andare similar to stored-value transactions in that specifically identifiedfunds are used to support the transactions. The source of funds for adebit transaction is specifically identified with a holder of theaccount that holds the funds and this account is usually ademand-deposit account maintained at a financial institution. As such,the funding of the account varies over time as deposits and withdrawalsare made from the account in response to receipt of wages, paying bills,etc. Debit accounts generally differ from stored-value accounts in thatthe account owner is provided with open-ended access, with all activitybeing based on the currently available funds level. Stored-valuetransactions might be considered to be a subset of debit transactions inwhich some money is set aside, but where there is no free access tofunds in the account. For instance, some stored-value accounts do notallow additional deposits, permitting only withdrawals to be made fromthe accounts in accordance with governing restrictions of the accounts.

The ability to transfer funds from a demand-deposit or other type ofaccount in such a short time period is enabled by the use of one or moreelectronic networks provided as part of a financial infrastructure.Communications routed over these networks permit decisions to be made inreal time whether the criteria for executing a transaction—validaccounts are identified, there are sufficient funds in the supportingaccount, identity-verification protocols have been satisfied, etc.—aremet. Such debit transactions are of particular interest to manymerchants because they remove the element of trust that is required ofother transactions. The time lag of check transactions runs the riskthat the check will be refused, forcing the merchant to expend time andeffort in recovering funds due for a previously executed transaction.And while credit transactions usually involve some authorizationprocess, there are mechanisms that may be used after the fact to preventthe payment from being made. From the perspective of merchants, debittransactions have the advantage that funds are received substantiallycontemporaneously with execution of the transaction itself. If there arelater disputes regarding the transaction, the merchant is in thesuperior position by having possession of the funds at that time.

There is accordingly a general need in the art for improved methods andsystems of supporting debit transactions.

BRIEF SUMMARY OF THE INVENTION

Embodiments of the invention provide methods and systems for executingfinancial transactions between customers and merchants. In a first setof embodiments, an identifier of a financial account is received fromthe customer at a merchant system. A one-time password is also receivedfrom the customer at the merchant system, with the customer having beenprovided with the one-time password by a mobile electronic device or acontactless presentation instrument. A cryptogram is generated, with thecryptogram comprising the identifier of the financial account encryptedusing the one-time password. An authorization request is formulated atthe merchant system. The authorization request comprises the cryptogramand transaction information describing at least a portion of thefinancial transaction. The authorization request is transmitted from themerchant system to an authorization processor for authorization of thefinancial transaction.

In a second set of embodiments, an encrypted authorization request isreceived from a merchant system at an authorization processor, with theauthorization request having been encrypted by application of a one-timepassword provided to the customer by a debit presentation instrument.The authorization request is decrypted. A financial account isidentified from the decrypted authorization request. Transactioninformation describing at least a portion of the financial transactionis determined from the decrypted authorization request. Authenticity ofthe transaction information is determined by validating the one-timepassword. It is determined whether the identified financial account iscapable of supporting the financial transaction based on the transactioninformation.

In either set of embodiments, there may be a number of specificfeatures. For example, the identifier may comprise an account number ofthe financial account. In other instances, it may comprise anidentification number extracted from a presentation instrument, with theidentification number being translated to an account number of thefinancial account. The one-time password may comprise a two-factorone-time password. In certain cases, the one-time password is a secondone-time password provided to the customer by the mobile electronicdevice after passage of an expiry time after a first one-time passwordis provided to the customer by the mobile electronic device. In somecases, an intermediate authentication processor translates theidentifier to a primary account number or card number that theauthorization processor recognizes. In certain embodiments, a personalidentification number is received from the customer at the merchantsystem, with the authorization request further comprising the personalidentification number. Cryptographic keys used to generate the one-timepassword on the presentation instrument, and to validate the one-timepassword on the authentication processor, may either be generated on thepresentation instrument and transferred to the authentication processor,or be generated on the authentication processor and transferred to thepresentation instrument.

The merchant system may sometimes comprise an Internet web server and,at other times, comprises a merchant point-of-sale device. The mobileelectronic device may comprise a cellular telephone. In someembodiments, the transaction information comprises a total cost for thefinancial transaction, or other descriptional data elements of thetransaction such as location, terminal identifier, terminal sequencenumber, date, and/or time.

Methods of the invention may also be embodied by a computer-readablestorage medium having a computer-readable program embodied therein fordirecting operation of a merchant system or of an authorizationprocessor, either of which may include a communications system, aprocessor, and a storage device. The computer-readable program includesinstructions for operating the respective devices to implement themethods as described above.

BRIEF DESCRIPTION OF THE DRAWINGS

A further understanding of the nature and advantages of the presentinvention may be realized by reference to the remaining portions of thespecification and the drawings wherein like reference numerals are usedthroughout the several drawings to refer to similar components. In someinstances, a sublabel is associated with a reference numeral and followsa hyphen to denote one of multiple similar components. When reference ismade to a reference numeral without specification to an existingsublabel, it is intended to refer to all such multiple similarcomponents.

FIG. 1 is a schematic illustration of a financial architecture withinwhich embodiments of the invention may be executed;

FIG. 2 is a schematic illustration of a computational unit that may beincluded as parts of elements of the financial architecture of FIG. 1;

FIG. 3 is a flow diagram summarizing methods of providing cards suitablefor use in contactless debit transactions to customers;

FIG. 4 is a flow diagram summarizing methods of enabling mobileelectronic devices to be used by customers in debit transactions;

FIG. 5 is a flow diagram summarizing enrollment methods used in someembodiments of the invention;

FIG. 6 is a flow diagram summarizing methods of executing debittransactions using the cards provided with the method of FIG. 3;

FIG. 7 is a flow diagram summarizing methods of executing debittransactions using mobile electronic devices configure according to themethod of FIG. 4; and

FIG. 8 is a flow diagram summarizing use of a federated authenticationweb service to execute transactions in accordance with certainembodiments of the invention.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the invention provide a number of different techniquesfor executing debit transactions. Some of these embodiments involve theuse of “contactless” transactions that make use of a presentationinstrument. In many instances, such a presentation instrument may take aform that is conventional in appearance, such as in the form of acredit-card-sized card, or may take a less conventional form, examplesof which include key fobs or other kinds of instruments. Contactlesstransactions may be executed in some embodiments with a mobileelectronic device. Transactions that are “contactless” are those thatare executed with only wireless interaction between the presentationinstrument and a merchant point-of-sale device. Conventional debittransactions involve contact between these elements because accountinformation is conventionally stored on one or more tracks of a magneticstripe that is affixed to the presentation instrument. These tracks areread by swiping the presentation instrument through a magnetic-stripereader comprised by the point-of-sale device. While some forms ofcontactless transaction have been attempted in the past, these haveinvolved such techniques as optically reading a bar code from apresentation instrument, often requiring that certain informationconventionally stored on the magnetic-stripe tracks be stored instead ina database that forms part of the financial architecture, i.e. eitherlocally to the point-of-sale device or at some other location incommunication with the point-of-sale device. Other forms of contactlesstransactions have involved transmission of the same data from thepresentation instrument to a the merchant point-of-sale device, as wouldhave been transmitted for a magnetic-stripe card. There are also anumber of security issues associated with such arrangements. Embodimentsof the invention use a structure in which both theinformation-management and security issues are better addressed.

Other embodiments of the invention provide techniques for using mobileelectronic devices in executing Internet-based transactions. Examples ofmobile electronic devices that may be used in different embodimentsinclude mobile telephones, personal digital assistants, and the like. Insome instances, the description may refer by way of example to the useof mobile telephones, it being understood that such references areintended merely to be illustrative and not to be limiting.

These various embodiments may be implemented in a financial architecturelike that shown in FIG. 1. In this illustration, the architecture 100 isstructured generally around a debit network 120, but it should berecognized that this is a depiction of only a portion of a largerfinancial infrastructure within which the architecture may be embodied.Other financial networks used in implementing credit, stored-value, orother types of transactions may be provided in communication with someof the elements shown in this drawing, even if not explicitly indicated.The debit network 120 generally comprises a private electroniccommunications network that implements security protocols commensuratewith the sensitive nature of the financial information that is routedthrough the network 120. Such security protocols and methods for theirimplementation are well known to those of skill in the art.

Interactions with the debit network 120 are provided through a varietyof different kinds of processors that are interfaced with the network.For example, front-end interactions may take place through an acquiringprocessor 116 that is in communication with the Internet 112 and/orpoint-of-sale devices 108 that are used in execution of the underlyingfinancial transactions. The back-end interactions may take place with anauthentication processor 124, the specific functionality of which isdescribed in further detail for some embodiments below.

Other communications within the architecture 100 may take place througha mobile network 110 that is interfaced with an over-the-air processor.The authentication processor 124 and over-the-air processor 126 may eachmake use of data stored in respective databases 128 and 130.

Endpoints of the architecture 100, at least from the perspective of thekinds of transactions discussed herein, are a customer 104 who interactswith the Internet 112 and/or point-of-sale device 108 to interface withthe front end and issuer systems 132 that are in communication with theauthentication processor 124. The issuer systems 132 may act asauthorization processors as described in specific detailed embodimentsbelow. In some instances, the customer 104 may have supplementaryinteractions with the architecture through a mobile electronic device106 and/or may use a contactless presentation instrument 107 dependingon specific implementations. These interactions proceed through themobile network 110 that is accessible by the mobile electronic deviceand that is in communication with the over-the-air processor 128. Eachof the issuer systems 132 is a computational system that is operated byan issuer of the presentation instrument or that manages the accountused to support the transaction. Such issuers are thus frequentlyfinancial institutions such as banks, credit unions, or the like, thatmaintain demand-deposit or other types of financial accounts that may beused to support debit transactions.

FIG. 2 provides a schematic illustration of a physical structure thatmay be used to implement different computational systems that may formpart of the architecture 100 of FIG. 1. For example, the computationalsystems 200 shown in FIG. 2 might correspond to a structure used for themobile electronic device 106, for the contactless presentationinstrument 107, for the acquiring processor 116, for the authenticationprocessor 124, for the over-the-air processor 126, and/or for any of theissuer systems 132 in different embodiments. FIG. 2 broadly illustrateshow individual system elements may be implemented in a separated or moreintegrated manner. The computational system 200 is shown comprised ofhardware elements that are electrically coupled via bus 226, including aprocessor 202, an input device 204, an output device 206, one or morestorage devices 208, a computer-readable storage media reader 210 a, acommunications system 214, a processing acceleration unit 216 such as aDSP or special-purpose processor, and a memory 218. Thecomputer-readable storage media reader 210 a is further connected to acomputer-readable storage medium 210 b, the combination comprehensivelyrepresenting remote, local, fixed, and/or removable storage devices plusstorage media for temporarily and/or more permanently containingcomputer-readable information. The communications system 214 maycomprise a wired, wireless, modem, and/or other type of interfacingconnection and permits data to be exchanged within the architecture 100to implement embodiments described herein.

The computational system 200 also comprises software elements, shown asbeing currently located within working memory 220, including anoperating system 224 and other code 222, such as a program designed toimplement methods of the invention. It will be apparent to those skilledin the art that substantial variations may be made in accordance withspecific requirements. For example, customized hardware might also beused and/or particular elements might be implemented in hardware(perhaps including tamper-resistant storage media for secure storage ofcryptographic keys), software (including portable software, such asapplets), or both. Further, connection to other computing devices suchas network input/output devices may be employed.

To participate in financial transaction methods of the invention, acustomer 104 may first be enrolled. Such enrollment establishes sets ofdata that may be used and manipulated in implementing embodiments of theinvention. Such data may be stored in the databases 128 and/or 130 aswell as on the presentation instrument and/or mobile electronic device106. A general overview of how enrollment may be accomplished inembodiments that use physical presentation instruments is provided withthe flow diagram of FIG. 3, while a corresponding overview of howenrollment may be accomplished in embodiments that make use of mobileelectronic devices is illustrated with the flow diagram of FIG. 4.

When contactless-card presentation instruments are issued by financialinstitutions, they are typically prepared using batch processes. Block304 of FIG. 3 accordingly indicates that a production file is preparedby an issuer processor. Such a production file typically includesinformation defining the nature of the individual presentationinstruments. For instance, when the presentation instruments comprisecards, the production file may include numbers to be embossed on thecards. It may also include information identifying the individuals to beassociated with each instrument, as well as identifying the financialaccount that will be used to support transactions executed with theinstruments. A manufacturer of presentation instruments may also produceblank versions of the instruments at block 308. For example, when thepresentation instruments comprise cards, blank versions of the cards maybe prepared by a card manufacturer that include a debit application thatwill be executed when performing debit transaction. Irrespective oftheir specific form, each of these instruments is equipped withstructure that enables them to be used in contactless communications.For example, the instrument may have an embedded electromagnetic chipthat receives and transmits electromagnetic signals at radio or otherfrequencies. Once created, these instruments are delivered by the cardmanufacturer to the card producer at block 312.

Having received the production file and the blank cards, the cardproducer may engage in personalization processes at block 316 by writinginformation to the blank instruments in accordance with thespecifications in the production file. This initial personalization mayinclude both direct physical alterations to the instrument, such as whencards are embossed with card numbers, and may additionally includewriting data to storage maintained on the instrument itself. Forinstance, card numbers, cryptographic keys, account or identificationnumbers, and/or merchant loyalty identification numbers, in addition toother data, may additionally be stored as data on the card so that thisinformation may be accessed and transmitted as appropriate inimplementing embodiments of the invention.

In addition to this personalization information, the card producer mayimplement certain encryption protocols that will be used in enhancingthe security of transactions executed with the instruments. In oneimplementation, public-key-private-key encryption is used within apublic-key infrastructure (“PKI”). Consistent with such aninfrastructure, at block 320 the card producer generates a PKI key pairfor each card, referred to herein as the “card encryption key pair.” Thepublic key of the pair is transmitted by the card producer, togetherwith an indication of the card number that it refers to, to theauthentication processor 124 at block 324 and the private key of thepair is retained on the card. Having been so prepared, the instrument isready for transmission to the customer at block 328.

In addition to this use of the production file by the card producer inpreparing the instruments, the production file may be provided to theauthentication processor 124 at block 132. The combination of theproduction file and the key information received from the card producerprovides the authentication processor 124 with sufficient information toauthenticate transactions as they are performed with the instruments.Both of these forms of information may be stored in database 128. Theindividual instruments may be activated after receipt by customers atblock 336 using a process defined by the issuer producer. In someinstances, this activation is performed by interactions between thecustomer 104 and the authentication processor 124, such as may beachieved over the Internet, through the use of a voice-response unit, orthe like. One purpose of this activation step is to reduce the risk offraud by confirming receipt of the instrument by the correct customer104. A comparison can accordingly be made between information providedby the customer 104 during this activation with information extractedfrom the production file by the authentication processor 124.

In some instances, the presentation instruments may be created withcertain redundancies of information. This is especially suitable, forexample, in embodiments where a card is to be equipped for bothcontactless and conventional transactions. Such multifunction cards mayinclude an electromagnetic chip such as a radio-frequency identificationchip to perform contactless transactions as well as a magnetic stripe orother mechanism that stores information that can be read by a device incontact with the card.

Some aspects of the enrollment shown in FIG. 4 for enrolling a mobileelectronic device 106 are similar to parts of the enrollment describedin connection with FIG. 3. The method may begin, for example, with thecustomer visiting an Internet web site managed by the over-the-airprocessor 126 at block 404. This web site acts as a provisioning website that may be used by the over-the-air processor 126 in effectingenrollment functions. The customer provides enrollment information atblock 408. Such enrollment information may comprise, for example, anidentification number that generally corresponds to the card number of adebit card in more conventional debit transactions, in addition to theaccess number for the mobile device 106 to be enrolled.

This information is used by the over-the-air processor 126 at block 412to enroll the identification number with the authentication processor124 at block 412. An exchange of verification information acts toconfirm that the correct mobile device 106 is enrolled. One example ofsuch an exchange shown in FIG. 4 involves the transmission of ashort-message-service (“SMS”) message to the mobile device 106identified by the access number provided at block 408. In one instance,the SMS message includes a provisioning URL that is used by the customerto confirm the verification information.

At block 424, the over-the-air processor 126 downloads a software debitapplication to the mobile device 106. The debit application resident onthe mobile electronic device 106 generates a cryptographic key at block428. This cryptographic key is a direct analogue of the key discussed inconnection with FIG. 3 for the generation of presentation instruments.As indicated at block 432, the debit application transmits thecryptographic key using the mobile device to the over-the-air process126. The over-the-air processor 126 then transmits it to the applicationprocessor 124 at block 436, resulting in the authentication processor124 now having all the requisite information to process a transaction inthe manner described below.

FIG. 5 is a flow diagram that summarizes a provisioning using theover-the-air processor 126 that may be used in some embodiments. Suchprovisioning permits enrollment to be accomplished by the customer usinga combination of information provided over an Internet connection to aweb site and information provided over a mobile network 110 from amobile electronic device 106. The method begins at block 504 with thecustomer visiting the enrollment web site. Once connected to this site,the customer enters the identification number at block 508. Similar tothe description of the processes of FIG. 4, such an identificationnumber may correspond to a more conventional card number of a debitcard.

In addition to this information, the customer enters the PIN on themobile electronic device 106 using an interface for doing generated fordisplay on the mobile electronic device. This information is transmittedfrom the mobile electronic device 106 over the mobile network 110 to theover-the-air processor 126 at block 516. The combination of informationis provided to the authentication processor 124, with the over-the-airprocessor 126 transmitting the PIN to the authentication process 124 atblock 520 and the enrollment web site transmitting the identificationnumber to the authentication processor 124 at block 524. Thiscombination of information is then used by the authentication processor124 at block 528 to complete the enrollment of the mobile electronicdevice 106, permitting it subsequently to be used as a presentationinstrument.

FIGS. 6 and 7 are flow diagrams that illustrate methods that may beimplemented to support debit transactions using the contactlesspresentation instruments or mobile electronic devices enrolled inaccordance with FIGS. 3 and 4. FIG. 6 provides an illustration ofmethods for executing and supporting debit transactions made using acontactless card. Such transactions generally take place at a physicalmerchant location, with the drawing accordingly indicating that themethod begins at block 604 with a customer selecting goods and/orservices for purchase at the merchant location. If the transaction isnot to be completed as a contactless transaction, the instrument may beswiped at block 648 to read information from a magnetic stripe orotherwise read with a device in contact with the instrument to proceedwith a conventional form of transaction.

If the transaction is to be executed as a contactless transaction, theinstrument is activated with a contactless mechanism at block 612. It isanticipated that such activation will normally be accomplished using anelectromagnetic mechanism, although any contactless mechanism that maybe implemented may be used in alternative embodiments.

The flow diagram also accounts for the fact that different kinds oftransactions may be supported as contactless transactions. Onedistinction that may be made among transactions is the need to supply apersonal identification number (“PIN”) as evidence of authorization touse the presentation instrument. The PIN is a number that is preferablykept secret by the account owner so that that person is the only oneauthorized to use the instrument, but in practice PIN's are sometimesshared with family members or friends who are authorized by the accountholder to execute transactions with the instrument. While the PIN offersa higher level of security for transactions, there are embodiments inwhich transactions will be permitted without verification of a PIN.These transactions are typically smaller transactions, so that aparticular embodiment might permit transactions to be executed without aPIN when they are less than $25 but require a PIN when the transactionsize exceeds $25. If the transaction is to be a PIN transaction aschecked at block 616, the customer enters the PIN information with thepoint-of-sale device 108 at block 652.

To execute any transaction, whether it requires a PIN or not, accountinformation is retrieved contactlessly from the presentation instrumentby the point-of-sale device 108. The content of this information mayvary in different embodiments, with it including or not including PINinformation in accordance with the type of transaction being executed.The account information is signed digitally with the card key that isresident on the presentation instrument at block 620. This signedaccount information is transmitted at block 624 in a contactless wayfrom the presentation instrument to the point-of-sale device 108.Merchant point-of-sale devices 108 may deliver transaction data elementsto the contactless presentation instrument during the contactlesstransaction session and such data elements may be included in derivationof the transaction digital signature.

With this information, the merchant point-of-sale device 108 hassufficient information to generate a transaction request at block 628 bycombining the signed account information with transaction information.The transaction information usually specifies at least a total amountfor the transaction and an account under the control of the merchant towhich the transaction amount is to be transferred. In certaincircumstances, the transaction information may include otherinformation, such as the location at which the transaction is to beexecuted, the specific items comprised by the transaction, and the like.The resulting transaction request is transmitted by the merchantpoint-of-sale device 108 to the authentication processor 124, which isthen equipped to parse the transaction request to extract theinformation needed to make an authentication decision. Thecustomer-account information comprised by the transaction request may beresolved with the card public key at block 632, permitting theauthentication processor 124 to identify the issuer and specific accountto be used in supporting the transaction.

With such a resolution, the decision-making process implemented by theauthentication processor 124 may be relatively simple. A check is madeby the at block 636 to validate the cryptogram included in the encryptedauthorization request transaction. If this authentication check fails, atransaction denial code is returned to the merchant point-of-sale device108 at block 656 so that the merchant can refuse the transaction orrequest some other financial support for it from the customer 104.

Upon successful completion of the authentication check at theauthentication processor, the authorization request transaction isforwarded to an authorization processor 132 to determine whether thereare sufficient funds in the identified account to cover the transactionamount. If there are sufficient funds in the identified account, aschecked at block 641, a transaction authorization code is returned bythe authentication processor 124 at block to the merchant point-of-saledevice 108, indicating to the merchant that the transaction may becompleted at block 644. Funds are debited in real time from the customeraccount and transferred to the control of the merchant by depositingthem into the merchant account identified with the transaction request.If there are insufficient funds, a transaction denial code may bereturned by the authentication processor 124 to the merchantpoint-of-sale device 108 at block 642.

In other embodiments, the authorization decision may be more complexthan simply considering whether the total transaction amount exceeds thefunds available in the customer account. For example, someimplementations include item-level restrictions that the funds may beapplied to so that the customer is restricted in use of those funds topurchasing only certain approved items. Alternatively, the customeraccount might be restricted so that its funds can only be applied totransactions executed at certain approved merchants. In each of theseand in other circumstances, the decision-making processes applied by theauthentication processor 124 may consider the data received as part ofthe transaction request on this more detailed level to determine whetherto authorize the transaction.

A number of aspects of transactions executed using a mobile electronicdevice as summarized with the flow diagram of FIG. 7 are similar toexecution of a contactless transaction. Block 704 indicates that thecustomer 104 selects goods and/or services to purchase from a merchantat block 704. These goods and services may be purchased at a merchantlocation or may be purchased remotely such as over the Internet 112, thedifferent transaction types resulting in different processing describedbelow.

A check is accordingly made of the transaction mode at block 708. If thetransaction occurs at a merchant location, a check may be made whetherto execute the transaction as a PIN or non-PIN transaction. This isindicated at block 712. Often such a decision hinges some characteristicof the transaction like its total size. If the transaction is to be aPIN transaction, the customer may enter the PIN using a keypad comprisedby the mobile electronic device 106. This may be included as part of theaccount information that is digitally signed and transmitted from themobile device 106 to the merchant point-of-sale device 108 at block 720.This digital signing is similar to the signing performed withcontactless cards in FIG. 6 by performing an encryption using thecryptographic key, but is performed by the mobile electronic device 106.

The signed account information is used by the merchant point-of-saledevice 108 in generating a transaction request that is then transmittedto the authentication processor at block 724. In addition to the signedaccount information, the transaction request may include details of thetransaction, usually including at least a transaction amount but perhapssometimes additionally including such information as item-levelidentifications of the specific goods and services that form part of thetransaction.

When an Internet-based transaction is to be performed, the customer mayenter the PIN using the keypad on the mobile device at block 730 and themobile device 106 may load a one-time password at block 728. In someembodiments, the one-time password comprises a two-factor one-timepassword. Conventionally, a number of different factors may be used toprovide security for authentication. For instance, such factors mayinclude something that the customer has, something that the customerknows, and something that the customer is. A two-factor one-timepassword is based on two such factors. In a particular implementation,the two factors are something that the customer has, such as possessionof the presentation instrument, and something that the customer knows,such as the PIN. The customer enters the identification number for hisaccount at block 732 with the password read from the mobile device. Thisprovides sufficient information for the merchant operating the web siteto generate an authorization request at block 736. The authorizationrequest is transmitted by the merchant web server to the authenticationprocessor 124 at block 740, permitting the authentication processor 124to use the one-time password to validate the authorization request atblock 744.

Subsequent processing of the transaction is similar to conventionalprocessing, irrespective of whether the authorization request isreceived from a point-of-sale device 106 or from a merchant web server.The authentication processor resolves the account information from theauthorization request at block 748 by applying decryption techniques. Ifthe digital signature fails to pass validation as checked at block 752,then a transaction denial code is returned by the authenticationprocessor 124 at block 754. If the digital signature passes validation,the transaction request is forwarded to the authorization processor 132at block 756, permitting a check to be made at block 758 whether thereare sufficient funds in the identified account. If not, a transactiondenial code is returned by the authorization processor 132 is returnedat block 760. If both the digital signature pass and there aresufficient funds in the account, the transaction is completed at block762.

FIG. 8 is a flow diagram that summarizes methods of executing certainInternet-based transactions. These methods may be implemented usingmerchants that provide web sites that participate in the program,sometimes referred to herein as implementing “federated authentication.”When a customer enters one of these participating web sites, asindicated at block 804, he or she may enter conventional identificationinformation to log into the web site at block 808. Such conventionalidentification information will frequently take the form of a userid,but may use other forms of identification known in the art. To completethe customer's authentication, the customer enters the PIN for thepresentation instrument on the mobile electronic device at block 812,with the device responding to correct entry of the PIN by displaying aone-time password at block 816. As in other embodiments of theinvention, the one-time password sometimes comprises a two-factorone-time password. This password is used by the customer to complete thelog in to the participating web site at block 820, permitting thecustomer to enter into and complete a transaction at block 824.

In some embodiments, the security information that is used in themethods described in connection with either FIG. 7 or FIG. 8 may varyover time. That is, when a two-factor one-time password is generated, itmay have a limited time of validity. In such embodiments, the customer104 must generally provide the password within the limited time tovalidate the transaction. After the time period has expired, a newone-time password is generated that must be received in order tovalidate the transaction within a separate time period. Such a featurefurther enhances the overall security of the transaction methods.

Thus, having described several embodiments, it will be recognized bythose of skill in the art that various modifications, alternativeconstructions, and equivalents may be used without departing from thespirit of the invention. Accordingly, the above description should notbe taken as limiting the scope of the invention, which is defined in thefollowing claims.

1. A method of executing a financial transaction between a customer anda merchant, the method comprising: receiving an encrypted authorizationrequest from a merchant system at an authorization processor, whereinthe authorization request was encrypted by application of a one-timepassword provided to the merchant by a presentation instrument;decrypting the authorization request; identifying a financial accountfrom the decrypted authorization request; determining transactioninformation describing at least a portion of the financial transactionfrom the decrypted authorization request; determining authenticity ofthe transaction information by validating the one-time password; anddetermining whether the identified financial account is capable ofsupporting the financial transaction based on the transactioninformation.
 2. The method recited in claim 1 further comprisingdelivering a loyalty customer identification number from thepresentation instrument to the merchant.
 3. The method recited in claim1 wherein the identifier comprises an account number of the financialaccount.
 4. The method recited in claim 1 wherein the one-time passwordcomprises a two-factor one-time password.
 5. The method recited in claim1 wherein the merchant system comprises an Internet web server.
 6. Themethod recited in claim 1 wherein the merchant system comprises amerchant point-of-sale device.
 7. The method recited in claim 1 furthercomprising verifying authenticity of the one-time password by validatingthe personal identification number associated with the identifiedfinancial account.
 8. The method recited in claim 1 wherein the debitpresentation instrument comprises a cellular telephone.
 9. The methodrecited in claim 1 wherein the transaction information comprises dataselected from the group consisting of a total cost for the financialtransaction, a location, a point-of-sale-device identifier, apoint-of-sale-device sequence number, a date, and a time.
 10. The methodrecited in claim 1 wherein the financial account comprises an accountselected from the group consisting of a debit account, a credit account,and a stored-value account.
 11. A computer-readable storage mediumhaving a computer-readable program embodied therein for directingoperation of an authorization processor to execute a financialtransaction between a customer and a merchant, the authorizationprocessor including a communications system, a processor, and a storagedevice, wherein the computer-readable program includes: instructions forreceiving an encrypted authorization request from a merchant system atthe authorization processor, wherein the authorization request wasencrypted by application of a one-time password provided to the customerby a presentation instrument; instructions for decrypting theauthorization request; instructions for identifying a financial accountfrom the decrypted authorization request; instructions for determiningtransaction information describing at least a portion of the financialtransaction from the decrypted authorization request; instructions fordetermining authenticity of the transaction information by validatingthe one-time password; and instructions for determining whether theidentified financial account is capable of supporting the financialtransaction based on the transaction information.
 12. The system recitedin claim 11 wherein the computer-readable program further includesinstructions for delivering a loyalty customer identification numberfrom the presentation instrument to the merchant.
 13. The system recitedin claim 11 wherein the identifier comprises an account number of thefinancial account.
 14. The system recited in claim 11 wherein theone-time password comprises a two-factor one-time password.
 15. Thesystem recited in claim 11 wherein the merchant system comprises anInternet web server.
 16. The system recited in claim 11 wherein themerchant system comprises a merchant point-of-sale device.
 17. Thesystem recited in claim 11 wherein the computer-readable program furtherincludes instructions for verifying authenticity of the one-timepassword by validating the personal identification number associatedwith the identified financial account.
 18. The system recited in claim11 wherein the debit presentation instrument comprises a cellulartelephone.
 19. The system recited in claim 11 wherein the transactioninformation comprises data selected from the group consisting of a totalcost for the financial transaction, a location, a point-of-sale-deviceidentifier, a point-of-sale-device sequence number, a date, and a time.20. The system recited in claim 11 wherein cryptographic keys used togenerate the one-time password on the presentation instrument aregenerated on the presentation instrument and transmitted to anauthentication processor or are generated on the authenticationprocessor and transmitted to the presentation instrument.
 21. The systemrecited in claim 11 wherein the financial account comprises an accountselected from the group consisting of a debit account, a credit account,and a stored-value account.